Пару недель назад на сайте проекта VMware Labs вышли обновления сразу нескольких утилит, поэтому вы, возможно, пропустили апдейты HCIBench 2.5 и 2.5.1. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.4 мы писали вот тут.

Давайте посмотрим, что нового появилось в версиях 2.5 и 2.5.1:

• Добавлена возможность тестирования в рамках топологии vSAN HCI Mesh, теперь можно добавлять локальные и удаленные датасторы vSAN одновременно.
• Добавлена поддержка локальных хранилищ, включая VMFS и тестирование vSAN-Direct.
• Новый режим vSAN Debug Mode, который позволяет автоматически собрать бандлы vm-support и vmkstats при тестировании vSAN.
• Изменена конвенция имен виртуальных машин на {vm_prefix}-{datastore_id}-batch_num-sequence_num.
• Улучшенный формат отчета о тестировании.
• Возможность указывать кастомные IP для тестовых машин.
• Возможность выставлять CPU и память для тестовых машин.
• Добавлено руководство по сетевому траблшутингу как раздел пользовательской документации.
• Возможность обновления на текущую и последующие версии одной командой:
  tdnf install -y git && git clone https://github.com/cwei44/HCIBench.git && sh HCIBench/upgrade.sh
MD5 Checksum: 1d14426f92b353e90469a8623ade2bc1 HCIBench_2.5.1.ova
• Исправлены ошибки с тестированием не-vSAN кластера, а также с превалидацией политики хранилищ.
• Прочие исправления ошибок.

Скачать VMware HCIBench 2.5.1 можно по этой ссылке.

На сайте проекта VMware Labs появилась очередная полезная штука - Storage Performance Tester. С помощью данного средства администраторы VMware vSphere могут в один клик проверить производительность хранилищ в плане IOPS, Latency и циклов CPU на одну операцию ввода-вывода для серверов VMware ESXi.

Эта утилита автоматизирует все шаги, которые необходимо предпринять для тестирования, включая развертывание виртуальных машин, запуск нагрузки по вводу-выводу, а также анализ производительности хранилища. Метрики, полученные в результате тестирования, визуализируются на графиках. Единственная вещь, которую вам нужно сделать - это выполнить соответствующую команду и ждать сгенерированного отчета о производительности хоста ESXi.

Средство создано как для администраторов платформы vSphere, так и для разработчиков, которым требуется решать проблемы производительности в виртуальной инфраструктуре. Также Storage Performance Tester удобно использовать для получения максимальных параметров производительности аппаратного обеспечения, а также программных компонентов (драйверы, настройки vSphere и vSAN).

Для запуска тестовой среды вам понадобятся:

• python3
• sshpass
• 2 ГБ свободного места
• Linux-окружения (с версией ядра не менее 2.6.31)

Вот небольшое обзорное видео, где можно посмотреть всю процедуру запуска утилиты и, собственно, сам отчет с результатами тестирования:

Скачать Storage Performance Tester можно по этой ссылке.

Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1, а также решения для создания отказоустойчивых хранилищ на базе хостов VMware vSAN 7 Update 1. В статье о vSAN мы упоминали о том, что VMware расширяет службы vSAN Native File Services за счет поддержки протокола SMB. Он интегрирован с Microsoft Active Directory и поддерживает аутентификацию Kerberos. Давайте посмотрим на эти возможности подробнее.

Во-первых, начнем с небольшого обзора от Дункана Эппинга:

Поддержка протокола SMB была введена в vSAN не просто так - целью была поддержка постоянных томов read-write many (RWM) volumes для cloud native applications (то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes). Для доступа поддерживаются хранилища SMB версий v2.1, так и v3 (SMB v1 находится в статусе Deprecated).

SMB-хранилища, создаваемые в vSAN, могут быть доступны из Windows-клиентов (версии 8/2012+) и Mac-клиентов (OS 10 и позднее). Это, совместно с поддержкой Active Directory, делает SMB-хранилища отличным вариантом для:

• VDI-сценариев, где пользователи предпочитают перенаправление каталога user/home на выделенную файловую шару.
• Файловые ресурсы, обслуживающие различные топологии (например, удаленные офисы или филиалы), могут управляться напрямую из vSAN, без необходимости иметь отдельную ВМ для предоставления общего доступа к папкам.

Файловые шары видны через Windows MMC, где администраторы могут: 

• Смотреть число клиентских соединений к шаре
• Смотреть число открытых файлов
• Управлять разрешениями и безопасностью (в стиле NTFS)
• Закрывать клиентские соединения
• Закрывать открытые файлы

Как мы писали выше, поддерживается и протокол аутентификации Kerberos, который предотвращает доступ NFS-клиентов через более уязвимые методы доступа, такие как auth_sys. vSAN поддерживает 3 модели аутентификации:

• KRB5, который проводит только безопасную аутентификацию (только на NFS v4.1)
• KRB5I, включая аутентификацию и проверку контрольных сумм
• KRB5P, включая аутентификацию, проверку контрольных сумм и шифрование

Надо отметить, что несмотря на то, что VMware vSphere 7 U1 поддерживает кластеры до 64 хостов, службы Native File Services поддерживают доступ до 32 хостов к файловым шарам.

Теперь службы Skyline Health (ранее это называлось "vSAN Health") содержат дополнительные хэлсчеки, включая file server health и share health:

Тут есть три основных типа проверок:

• Проверки Infrastructure health checks - развернута ли машина FSVM и демон VDFS, а также есть ли файловая система root на хосте. Если чего-то из этого нет, то проверка показывает красный сигнал.
• Проверки File Server Health checks показывают, все ли в порядке с файловым сервером на отдельных хостах, и есть ли там файловая система root. Если что-то из этого не в порядке - показывается красный сигнал.
• Проверки Share Health отвечают за статус объектов файловых шар. Если служба протокола не работает для данного объекта, то показывается красный сигнал. Также могут быть оповещения для шар - и тогда будет желтый.

Для файловых шар SMB появился мониторинг производительности в интерфейсе vSAN UI. Можно смотреть за пропускной способностью (throughput), IOPS, задержками (latency) на уровне отдельной шары в реальном времени. Можно увеличивать временное окно просмотра для отдельных метрик. Также эти метрики доступны через API, поэтому такие продукты, как vRealize Operations также будут их использовать.

Доступную емкость SMB-хранилищ можно отслеживать через vSAN Capacity view:

Если вы нажмете на ссылку File shares overview в левом нижнем углу, то сможете открыть просмотр емкости на уровне отдельных шар. На картинке ниже представлен микс из SMB и NFS хранилищ, столбики в Usage/Quota показывают жесткие аппаратные квоты с цветовым кодированием заполненности:

Ну и напоследок небольшой обзор VMware vSAN File Services от VMware:

Компания VMware анонсировала новую версию платформы для создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 7.0 Update 1. Напомним, что о прошлой версии vSAN 7 мы писали вот тут.

Данная версия vSAN сфокусирована на функциях по обеспечению эффективности датацентра, которые нацелены на увеличения возврата инвестиций в оборудование и программное обеспечение:

Новые возможности VMware vSAN 7 U1 можно разделить на 3 категории:

• Эффективность и производительность
• Упрощение операций с инфраструктурой хранения
• Интеграция с облачной инфраструктурой

1. Технология HCI Mesh

Главная из новых возможностей - это технология VMware HCI Mesh, которая позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):

В такой схеме можно использовать несколько кластеров-клиентов для монтирования датастора, но надо соблюдать правило доступа: не более 64 хостов ESXi к одному датастору, включая хосты серверного кластера.

В такой конфигурации можно делать vMotion виртуальных машин между кластерами vSAN, но хранилище (Storage vMotion) при этом перемещать нельзя.

Также в топологии HCI Mesh можно использовать подход Full Mesh, когда один и тот же кластер выступает и клиентом, и сервером:

Подход Full Mesh позволит вам сбалансировать потребление емкости кластеров хранилищ. При этом есть ограничение: каждый серверный кластер может экспортировать не более 5 датасторов для клиентских кластеров, а каждый клиентский - монтировать не более 5 датасторов серверных кластеров.

Особенности технологии HCI Mesh:

• Минимальное число узлов кластера-клиента и кластера-сервера - 2 узла
• Технически Compute-only vSAN cluster (без своих датасторов) сейчас работает, но не рекомендуется к использованию и не поддерживается
• Поддерживается одновременное использование хранилищ Hybrid (SSD+HDD) и All-Flash одновременно

Небольшой обзор технологии:

2. Поддержка SMB для vSAN Native File Services

VMware расширяет службы vSAN Native File Services за счет поддержки протокола SMB. Он интегрирован с Microsoft Active Directory и поддерживает аутентификацию Kerberos. Таким образом, vSAN теперь поддерживает NFS (версии 3 и 4.1) и SMB.

3. Шифрование vSAN Data-in-Transit Encryption

Теперь в vSAN 7 Update 1 есть возможность шифрования при передаче данных между узлами кластера по протоколу TCP с использованием крипто-модуля FIPS-2. При этом вам не потребуется использовать Key Management Server (KMS).

Также надо отметить, что одновременное использование HCI Mesh и Data-in-Transit Encryption не поддерживается.

4. Техника SSD Secure Erase

В vSAN 7 Update 1 появился надежный способ удаления данных с SSD-дисков. Пока это поддерживается только для оборудования Dell и HPE. Например, это можно будет использовать для готовых серверных узлов vSAN Ready Nodes и комплектов DellEMC VxRail.

5. Общая оптимизация производительности

Как и всегда, VMware проводит работу над улучшением vSAN в контексте производительности. Заявляется, что vSAN 7 Update 1 работает примерно на 30% быстрее при выполнении операций, чем vSAN 6.7 U3 (который до этого был самым производительным).

6. Возможность использования компрессии без дедупликации

Ранее vSAN позволял использовать две этих технологии только вместе, а сейчас можно использовать только сжатие данных, не нагружая вычислительные ресурсы движком дедупликации. Теперь технология работает так:

Дедупликация

• На уровне дисковой группы
• Работает при дестейджинге данных на capacity tier
• Работа с фиксированными блоками 4 КБ

Компрессия

• Работает после дедупликации, но до того, как данные дестейджатся
• Если блок можно сжать до 2 КБ или менее, то он сжимается
• Иначе сохраняется блок 4 КБ

Компрессия работает значительно быстрее дедупликации, поэтому ее отдельно удобно использовать для OLTP-нагрузок.

7. Функция Enhanced durability при выполнении операций обслуживания

Если хост ESXi находится в режиме обслуживания (maintenance mode), то vSAN теперь имеет механизм защиты данных, которые в этот период находятся только в одном экземпляре (у них был задан failures to tolerate равный 1, а а хост перевели в режим обслуживания - и теперь есть только одна активная реплика данных).

В таком случае vSAN понимает, что у вас был FTT=1, и на время обслуживания все операции записи начинает дублировать на выделенный хост для delta writes, чтобы вы не потеряли данные во время отказа хоста с единственной копией данных:

При выходе хоста ESXi из режима обслуживания происходит обновление его данных с временного хранилища, после чего оно высвобождается для дальнейшего использования. Интересно, что для этих целей можно использовать и witness-хост.

Данный механизм можно использовать как для RAID Mirroring, так и для Erasure Coding.

8. Быстрая перезагрузка и ускоренный апгрейд кластеров

• Существенное ускорение апгрейда кластеров за счет более быстрой перезагрузки хостов
• Метаданные хоста записываются на диск перед перезагрузкой и восстанавливаются в память после загрузки - это ускоряет актуализацию метаданных
• Как результат - хосты загружаются до 5 раз быстрее

9. Общий witness-хост для нескольких кластеров

Это очень удобно для ROBO-инсталляций. vSAN 7 Update 1 поддерживает до 64 кластеров в двухузловых конфигурациях с общим witness для ROBO-сценариев (это решения для удаленных офисов и филиалов - Remote or Branch Offices).

10. Оптимизация всегда доступной емкости (Slack Space)

По рекомендациям VMware нужно было всегда держать 25-30% свободной емкости хранилищ в кластере. Это называлось Slack Space. Теперь это называется Reserved Capacity, и ее необходимый объем зависит о числа узлов в кластере (чем меньше узлов - тем меньше емкость), например:

• 12 node cluster = ~16%
• 24 node cluster = ~12%
• 48 node cluster =~ 10%

Эта емкость нужна для:

• Операций Resync при изменении политик, ребалансировке, перемещении данных (Operations Reserve)
• Активностей Rebuild при отказах хранилищ и хостов (Host Rebuild Reserve)

Надо понимать, что Reserved Capacity предотвращает только развертывание новых виртуальных машин, но не затрагивает ввод-вывод уже имеющихся.

Также Reserved Capacity - это опциональный механизм, который не включен по умолчанию:

Функция vSAN Reserved Capacity не поддерживается для растянутых кластеров и двухузловых конфигураций.

11. Улучшения vSphere Lifecycle Manager (vLCM)

Еще в vSAN 7 поддерживались узлы Dell и HPE для решения vLCM, теперь же к ним добавилось и оборудование Lenovo ReadyNode.

Сам vLCM получил следующие улучшения:

• Работа с vSAN Fault Domains, двухузловыми конфигурациями и растянутыми кластерами (Stretched Clusters)
• Предпроверки Hardware compatibility pre-checks
• Параллельное обновление кластера до 64 хостов
• Поддержка окружений с NSX-T 3.1

12. Упрощенная маршрутизация для некоторых топологий

Раньше для топологии vSAN с внешним witness должны были иметь статическую маршрутизацию. Теперь в vSAN 7 Update 1 можно добавить шлюз по умолчанию и не прописывать статические маршруты:

13. Утилита vSAN I/O Insight

С помощью этого средства можно анализировать I/O-паттерны для анализа рабочих нагрузок в кластере. Это утилита, встроенная в vSphere Client, в которой доступен большой набор паттернов метрик и гистограмм для анализа таких вещей, как R/W ratio, Seq/Random ratio, 4K aligned / unaligned ratio, IO size distribution.

Все это позволяет не пользоваться сторонними утилитами для решения узких проблем, а понимать их природу прямо из vSphere Client:

14. Улучшения сервисов для Cloud native applications

• Платформа vSAN Data Persistence - это новый фреймворк для партнеров, который позволяет интегрировать информацию о приложениях для операционных задач через API.
• SAN Direct Configuration - это альтернативный способ для прямой интеграции сервисов с хранилищами vSAN.
• Улучшения интеграции с vSphere with Tanzu за счет расширений для томов гостевых кластеров TKG, а также получения информации о состоянии томов TKG supervisor и guest.

Доступность для загрузки VMware vSAN 7 Update 1 ожидается в самое ближайшее время, следите за нашими новостями.

Это статья нашего спонсора - компании ИТ-ГРАД, предоставляющей в аренду виртуальные машины из облака. Гиперконвергентность – быстрорастущий сегмент СХД. Переход от традиционной архитектуры к HCI выбирают все больше компаний. Хотите узнать почему? В статье мы ответим на этот вопрос и расскажем для каких задач подходит VMware vSAN...

Иногда в кластере хранилищ VMware vSAN случается такая ситуация, что один из хостов ESXi оказывается "пустым", то есть не содержит компонентов виртуальных машин. При этом хранилища остальных хостов в кластере могут быть загружены почти полностью.

В этом случае надо посмотреть на интерфейс vSphere Client в разделе vSAN health check - там может быть такое сообщение для проблемного хоста:

vSAN node decommission state

Означает это, что хост находится в режиме обслуживания с точки зрения vSAN (Node Decommission State). При этом, например, с точки зрения хостов ESXi кластера VMware vSphere / HA он может не быть в maintenance mode. Поэтому может сложиться впечатление, что хост просто не принимает дисковые объекты по каким-то причинам.

Это состояние рассинхрона кластера vSphere и кластера vSAN. Лечится следующей командой по SSH, которая выведет узел vSAN из режима обслуживания, после чего он оживет на прием компонентов:

localcli vsan maintenancemode cancel

Также вы можете кликнуть правой кнопкой на хосте ESXi, перевести его в режим обслуживания, а потом вернуть обратно:

Это отменит и перевод в режим обслуживания vSAN, после чего хост сможет размещать дисковые объекты виртуальных машин (для этого надо запустить операцию Rebalance). Более подробно об этом в KB 51464.

На сайте проекта VMware Hans-on Labs (HOL) появились две новые лабораторные работы, посвященные новой версии продукта для создания отказоустойчивых хранилищ VMware vSAN 7.

• HOL-2108-01-HCI – What’s new in vSAN – Getting Started
• HOL-2108-91-HCI – vSAN Quick Start – Lightening Lab

Лабораторные работы VMware HoL позволяют освоить работу с различными продуктами и технологиями, проходя по шагам интерфейса. Такой способ отлично подходит для обучения работе с новыми версиями решений без необходимости их развертывания.

Напомним, что в последнее время мы уже писали об обновлениях лабораторных работ:

• 18 новых лабораторных работ (Hands-On Labs) на тему vCloud Management Platform
• Новые лабораторные работы (Hands-on Labs) на VMware vSphere 7

Первая лабораторная работа "What's New in vSAN 7" охватывает следующие аспекты развертывания и эксплуатации продукта:

• Политики хранилищ и средства обеспечения доступности (vSAN SPBM and Availability)
• Файловые службы для работы с протоколами NFS и SMB - vSAN File Services
• Хранилища vSAN Cloud Native Storage (CNS) для контейнеров кластеров Kubernetes
• Мониторинг состояния, доступных емкостей и производительности
• Облуживание и управление жизненным циклом хранилищ и виртуальных машин
• Шифрование и безопаность платформы

Вторая лабораторная работа посвящена мастеру QuickStart для пошагового создания кластера хранилищ vSAN, с помощью которого можно быстро освоить его основные настройки и конфигурации:

Несмотря на то, что компания VMware представила версию средства для создания отказоустойчивых хранилищ vSAN 6.5 еще в 2016 году, многие крупные компании продолжают ей пользоваться. Между тем, надо понимать, что скоро браузеры отключат поддержку Flash, и все консоли на базе этой технологии (а именно на ней работает старый vSphere Web Client) просто прекратят работать (в Chrome это запланировано на декабрь этого года).

Чтобы вы могли и дальше использовать vSAN 6.5, нужно накатить патч vSAN 6.6.1 Patch 05 (вышел еще 30 июля), в котором добавлена поддержка технологии HTML5, поддерживающейся всеми современными браузерами. О возможностях vSAN 6.6.1 мы писали вот тут.

В новом апдейте vSAN 6.6.1 на базе мажорной версии 6.5 есть следующие нововведения:

• Отчеты о производительности вы можете найти в Cluster > вкладка Monitor > секция vSAN > Performance
• Добавлена панель общей информации в разделе Virtual object, показывающая размещение и доступность объектов в кластере. Также можно фильтровать список по статусу и типу объектов.
• В разделе Virtual Objects/ View data placement есть чекбокс "Group components by host placement", который дает возможность увидеть состояние компонентов данных и быстрее обнаружить потенциальные проблемы на хостах ESXi.

Также из блога VMware мы утянули вот такое видео с обзором интерфейса HTML5 для vSAN 6.6.1:

Четыре года назад мы публиковали табличку, которая показывает соответствие билдов различных продуктов VMware их официальным версиям (а до этого мы публиковали табличку 6 лет назад).

С тех пор много чего изменилось, в том числе добавились новые продукты, поэтому ниже таблица с нужными ссылками для соответствующих продуктов и датами релизов:

Все перечисленные ссылки агрегированы в KB 1014508.

Многие из вас знают, что в решении для организации отказоустойчивых кластеров хранилищ VMware vSAN есть функции дедупликации и сжатия данных (deduplication and compression, DD&C). С помощью этих функций можно более эффективно использовать ярус хранения данных виртуальных машин (Capacity Tier). О некоторых аспектах применения дедупликации и сжатия данных в vSAN мы рассказывали вот тут, а сегодня поговорим об их общем влиянии на производительность дисковой подсистемы.

Как знают администраторы vSAN, это решение использует двухъярусную архитектуру, создающую оптимальное соотношение цена/качество для хранилищ ВМ - на Cache Tier, собранном из дорогих SSD-дисков (быстро работающих на дисках), размещается Write Buffer и Read Cache, а на дешевых SSD/HDD-дисках - постоянные данные виртуальных машин.

Механизм DD&C работает так - если он включен, то как только из Cache Tier виртуальной машине отправляется квитанция о записи данных, то может начаться процесс дестейджинга данных на Capacity Tier, во время которого сам механизм и вступает в действие. Сначала с помощью механики дедупликации в рамках дисковой группы (deduplication domain) находятся идентичные блоки размером 4 КБ и дедуплицируются, а затем блоки сжимаются. При этом, если блок сжимается менее, чем на 50%, то целевое хранилище записывается оригинал блока в целях быстрого доступа при чтении (без декомпрессии).

Получается, что механизм DD&C - оппортунистический, то есть он работает не всегда, а по мере возможности и не гарантирует конкретных результатов по эффективности сжатия данных на целевом хранилище.

Такая модель позволяет не затрагивать процесс посылки квитанции виртуальной машине о записи данных, а также не заморачиваться с дедупликацией блоков уже на целевом хранилище в рамках пост-процессинга.

Очевидно, что дедупликация с компрессией могут влиять на производительность, так как требуют ресурсов процессора на обработку потока ввода-вывода. Давайте посмотрим, как именно.

При высоком входящем потоке операций чтения и записи vSAN старается обеспечить наименьшую задержку (latency) при прохождении команд. При этом vSAN сам решает, в какой именно момент начать процесс дестейджинга данных, поэтому буфер на запись заполняется разные моменты по-разному.

Такая двухъярусная система vSAN имеет 2 теоретических максимума:

• Max burst rate - возможность Cache Tier сбрасывать обработанные пакеты данных в сторону Capacity Tier
• Max steady state rate - установившаяся максимальная скорость записи данных на приемнике Capacity Tier

Реальная скорость обмена данными между ярусами лежит где-то между этими значениями. Если вы будете использовать бенчмарк HCIBench на длительном отрезке времени, то сможете практическим путем определить эти значения из соответствующих графиков замера производительности хранилища.

Если у вас идет дестейджинг данных с включенным DD&C, это потенциально может повлиять на производительность записи данных на Capacity Tier. При использовании DD&C снижается максимальная скорость записи данных на ярус постоянного хранения, так как перед этой записью должны быть выполнены операции дедупликации и сжатия.

Иными словами, кластер с включенным DD&C может давать такие же показатели качества обслуживания, как и кластер с более медленными устройствами в Capacity Tier, но с выключенным DD&C.

Логично ожидать, что при включенном DD&C буффер Write Buffer будет заполняться скорее, так как будут возникать задержки ожидания отработки DD&C. Но пока буффер полностью не заполнен - заметных просадок в производительности не будет. Очищаться также Write Buffer будет медленнее при включенном DD&C.

Также может измениться и время отсылки квитанции о записи (acknowledgment time, оно же write latency), которое увеличит latency для виртуальной машины. Это произойдет, если уже начался дестейджинг данных, а машина запрашивает ACK и ждет ответа с уровня буффера. Хотя в целом vSAN построен таким образом, чтобы как можно быстрее такой ответ дать.

Надо отметить, что vSAN не торопится сразу скинуть все данные из Write Buffer на диск. В vSAN есть интеллектуальные алгоритмы, которые позволяют делать это равномерно и вовремя, с учетом общей текущей нагрузки. Например, при частой перезаписи данных одной ячейки памяти, она обрабатывается в цепочке сначала именно на уровне буффера, а на диск уже идет финальный результат.

Если вы также используете RAID 5/6 для кластеров vSAN, то совместно с техниками DD&C могут возникнуть серьезные эффекты с влиянием на производительность. Об этих аспектах подробно рассказано вот тут - обязательно ознакомьтесь с ними (см. также комментарий к статье).

По итогу можно сделать следующие выводы из этой схемы:

• Если вам хочется использовать DD&C, и вы видите, что у ВМ высокая latency - попробуйте более быстрые диски на Capacity Tier.
• Используйте больше дисковых групп, так как Buffer и его пространство hot working set используется на уровне дисковой группы. Две группы на хосте нужно минимум, а лучше три.
• Альтернативой DD&C могут стать устройства большой емкости - там просто все поместится).
• Используйте последнюю версию vSAN - алгоритмы работы с данными все время совершенствуются.
• Также помните, что RAID 5/6 также экономит место по сравнению с RAID1, что может стать альтернативой DD&C.

Ну и главный вывод он как всегда один: производительность - это всегда компромисс между требованиями рабочих нагрузок и деньгами, которые вы готовы потратить на обеспечение этих требований.

В начале апреля компания VMware обновила свой основной фреймворк для управления виртуальной инфраструктурой с помощью командных сценариев PowerShell до версии PowerCLI 12.0. Напомним, что прошлая версия PowerCLI 11.5 вышла осенью прошлого года.

Давайте посмотрим, что нового появилось в двенадцатой версии фреймворка:

• Добавлены командлеты для управления хостовой сетью ESXi

Еще в vSphere 6.0 появилась поддержка сетевых стеков хостов ESXi. Она позволяет назначить различные шлюзы для адаптеров VMkernel в целях маршрутизации трафика. Через PowerCLI можно использовать ESXCLI или API для управления этой функциональностью с помощью командлетов Get-VMHostNetworkStack и Set-VMHostNetworkStack. Новый параметр называется "NetworkStack", он был добавлен в командлет New-VMHostNetworkAdapter:

• Добавлены командлеты для управления решением HCX
• Появились новые командлеты для управления пространствами имен
• Командлеты для управления службами Trusted Host Services
• Командлеты для управления диском гостевой ОС виртуальных машин (VM Guest Disk management)

Теперь раздел гостевой ОС можно замапить на VMDK-диск (пока только для Windows-систем). Для этого потребуется vSphere 7 и VMware Tools не ниже 11-й версии. Эту возможность можно использовать с помощью командлета Get-VMGuestDisk:

• Новые командлеты для управления VMware Cloud on AWS
• Новые командлеты для vSAN:
  • Get-VsanFileServiceDomain
  • New-VsanFileServiceDomain
  • Set-VsanFileServiceDomain
  • Remove-VsanFileServiceDomain
  • New-VsanFileServiceIpConfig
  • Get-VsanFileShare
  • New-VsanFileShare
  • Set-VsanFileShare
  • Remove-VsanFileShare
  • New-VsanFileShareNetworkPermission
  • Add-VsanFileServiceOvf
  • Get-VsanFileServiceOvfInfo
• Новый модуль для управления службами VMware Cloud Services
• Добавлена поддержка vSphere 7.0
• Добавлена поддержка vRealize Operations 8.0
• Обновлена поддержка модулей License и vROps, а также командлета Open-VMConsoleWindow для использования на различных платформах
• Поддержка Move-VM для сетей opaque networks
• Добавлена поддержка последних обновлений PowerShell 7.0:

Скачать VMware PowerCLI 12.0 можно по этой ссылке. Полезные ресурсы:

• Release Notes
• VMware PowerCLI 12.0.0 User’s Guide
• VMware PowerCLI 12.0.0 Cmdlet Reference

Не так давно мы писали о новых возможностях платформы для создания отказоустойчивых хранилищ виртуальных машин в инфраструктуре виртуализации VMware vSAN 7.0. Компания VMware недавно сделала доступными для загрузки все компоненты обновленной виртуальной инфраструктуры, но новые возможности получили далеко не все пользователи - их набор зависит от имеющейся лицензии.

Давайте посмотрим, какие возможности есть в каждом из четырех доступных изданий VMware vSAN 7.0:

	Standard (гибридные хранилища HDD+SSD)	Advanced (All-Flash хранилища)	Enterprise (возможности для предприятий)	Enterprise Plus (гиперконвергентная инфраструктура)
Возможности vSAN 7
Политики хранилищ Storage Policy Based Management (SPBM)
Распределенный коммутатор Virtual Distributed Switch
Распределение дисковых объектов по разным стойкам (Rack Awareness)
Контрольные суммы и обнаружение сбоев (Software Checksum)
Возможность использования оборудования All-Flash
Службы iSCSI Target
Функции QoS – IOPS Limit
Интерфейс управления HTML5
Функции Cloud Native Storage
Дедупликация и компрессия данных
Функции RAID-5/6 Erasure Coding
Возможности vRealize Operations внутри vCenter
Растянутый кластер (Stretched Cluster) с защитой от локальных сбоев
Шифрование Data-at-rest
Файловые службы
Издание vRealize Operations 8.0 Advanced
Функции балансировщика с поддержкой vSAN (resync, slack space, SPBM)
Кастомизируемые дэшборды
Функции Auto Remediation
Рабочие процессы для решения проблем
Функции интеллектуального размещения нагрузок Automated Intent-Based Workload Placement
Планирование емкостей (Capacity Planning)

Вчера компания VMware объявила о доступности для загрузки (General Availability) своей флагманской платформы виртуализации VMware vSphere 7. Скачать ее можно по этой ссылке.

Объявление о доступности продукта было сделано во время почти часовой онлайн-сессии:

Одновременно стали доступны для скачивания и следующие решения:

• VMware vSAN 7
• VMware Site Recovery Manager 8.3
• VMware Horizon 7.12

Напомним все наши статьи, относящиеся к данному релизу и другим обновлениям продуктовой линейки VMware:

• Анонсирована новая версия VMware vSphere 7 - что нового?
• Новые возможности VMware Site Recovery Manager 8.3 и vSphere Replication
• Анонсирована новая версия VMware vSAN 7.0 - что там будет интересного?
• Что нового в VMware vRealize Operations 8.1 - самое главное
• Новые возможности решения для виртуализации и доставки настольных ПК предприятия VMware Horizon 7.12
• Новые возможности Dynamic Environment Manager 9.11
• Что нового в VMware Cloud Foundation 4?

Что еще есть интересного по теме:

• VMware vSphere 7 Upgrade Center
• VMware vSphere 7 Release Notes
• vSphere 7 YouTube Playlist
• vSphere Academy
• vSphere Central

Из больших релизов осталось ждать только vRealize Operations 8.1.

Как вы знаете, все офлайн-мероприятия этой весны отменены, набирает популярность формат онлайн-конференций. VMware в этом смысле уже давно не новичок - она регулярно проводит подобные конференции, где виртуально собираются тысячи людей со всего мира.

13 мая в этом году пройдет VMware vFORUM 2020 Online, где в течение половины дня сотрудники VMware будут рассказывать о самых последних продуктах и технологиях компании. Интересно, что форум пройдет в удобное вечернее время: с 19-00 мск до часа ночи.

Основные темы:

• Multi-Cloud - управление гибридными инфраструктурами.
• Modern Applications - все о контейнеризованных приложениях и кластерах Kubernetes в виртуальной среде.
• Virtual Cloud Networking - соединение виртуальных машин и приложений в распределенной инфраструктуре датацентров.
• Digital Workspace - управление мобильными средами, используемыми на разных платформах.
• Intrinsic Security - обеспечение безопасности сетей, рабочих станций, виртуальных машин и облаков в целом.

Вот так выглядит план мероприятия, включающего в себя 38 технических сессий с более чем 130 экспертами:

Также в рамках форума будет 10 лабораторных работ (Hands-On Labs) по продуктам vSphere, vSAN, VMware Cloud on AWS, Carbon Black и Workspace ONE.

Регистрация на VMware vFORUM 2020 Online здесь.

Кластер отказоустойчивых хранилищ VMware vSAN состоит из нескольких хостов ESXi, на локальных хранилищах которых создаются дисковые группы, где размещаются данные виртуальных машин. В процессе создания, перемещения и удаления дисковых объектов ВМ распределение емкости на дисках может изменяться, иногда довольно существенно.

Все это приводит к дисбалансу кластера по дисковой емкости, что создает разную нагрузку на устройства, а это не очень хорошо:

В случае возникновения подобного дисбаланса в кластере VMware vSAN, в консоли vSphere Client на вкладке Monitor, в разделе vSAN Health появляется нотификация vSAN Disk Balance (выполняется эта проверка каждые 30 минут по умолчанию):

Чтобы устранить подобные ситуации, в кластере VMware vSAN есть механизм автоматической балансировки - Automatic Rebalance, который относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства.

По умолчанию пороговое значение составляет 30% (параметр Average Load Varinace - среднее значение разницы между минимальной и максимальной используемой емкостью на дисках в процентах). Это означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется автоматическая перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.

Также перебалансировка сама запустится, когда диск заполнен на более чем 80%. Надо помнить, что операция эта создает нагрузку на дисковые хранилища, поэтому надо учитывать, что у вас должен быть некоторый запас по производительности, чтобы автоматическая балансировка не съела полезные ресурсы.

В случае если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.

Эта опция называется ручной проактивной балансировкой кластера, она становится доступной когда разница в использовании дисковой емкости двух или более дисков начинает превышать 30%:

Если вы запускаете такую балансировку вручную, то продлится она по умолчанию 24 часа и затем сама остановится.

Надо понимать, что операция ребалансировки - это совершенно другая операция, нежели vSAN Resync. Она служит только целям сохранения равномерной нагрузки в кластере с точки зрения дисков.

Также есть возможность контроля операций ребалансировки с помощью интерфейса Ruby vSphere Console (RVC). Для этого вам нужно сменить пространство имен (namespace) на computers и выполнить следующую команду для кластера, чтобы посмотреть информацию о текущем балансе:

vsan.proactive_rebalance_info <номер кластера vSAN или символ "." для текущего пути консоли RVC>

Результат выполнения команды будет, например, таким:

/localhost/Test-DC/computers/Test-CL> vsan.proactive_rebalance_info .

  2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-3.labs.org ...

  2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-1.labs.org ...

  2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-2.labs.org ...

  2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-3.labs.org (may take a moment) ...

  2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-2.labs.org (may take a moment) ...

  2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-1.labs.org (may take a moment) ...

  2019-08-16 19:31:10 +0000: Done fetching vSAN disk infos
  Proactive rebalance start: 2019-08-16 19:30:47 UTC

  Proactive rebalance stop: 2019-08-17 19:30:54 UTC

  Max usage difference triggering rebalancing: 30.00%

  Average disk usage: 56.00%

  Maximum disk usage: 63.00% (17.00% above minimum disk usage)

  Imbalance index: 10.00%

  No disk detected to be rebalanced
 

В этом случае ребалансировка не требуется. Если же вы, все-таки, хотите ее запустить, то делается это следующей командой:

vsan.proactive_rebalance -s <номер кластера vSAN или символ "." для текущего пути консоли RVC>

Вы увидите нечто подобное:

/localhost/Test-DC/computers/Test-CL> vsan.proactive_rebalance . -s

  2019-08-16 19:30:55 +0000: Processing vSAN proactive rebalance on host esxi-3.labs.org ...

  2019-08-16 19:30:55 +0000: Processing vSAN proactive rebalance on host esxi-1.labs.org ...

  2019-08-16 19:30:55 +0000: Processing vSAN proactive rebalance on host esxi-2.labs.org ...
  

В любой момент вы также можете проверить статус ребалансировки в конкретном кластере командой:

vsan.proactive_rebalance_info <номер кластера vSAN>

Ну и вы можете изменить время, в течение которого будет идти ручная ребалансировка. Для этого задайте значение в секундах следующей командой (в данном примере - это 7 дней):

vsan.proactive_rebalance . -t 604800

На днях компания VMware объявила о скором выпуске платформы виртуализации VMware vSphere 7.0, где будет много интересных новых возможностей. Одновременно с этим было объявлено и о будущем релизе новой версии VMware vSAN 7.0 - решения для организации отказоустойчивых хранилищ для виртуальных машин на базе локальных хранилищ хост-серверов VMware ESXi.

Давайте посмотрим, что интересного было анонсировано в новой версии решения VMware vSAN 7:

1. Интеграция с vSphere Lifecycle Manager (vLCM) для обновления кластеров

Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager:

vLCM можно использовать для применения установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. Это упрощает мониторинг инфраструктуры на предмет своевременных обновлений и соответствия компонентов руководству VMware Compatibility Guide (VCG) за счет централизованного подхода на уровне всего кластера.

2. Службы Native File Services for vSAN

С помощью служб Native File Services кластер vSAN теперь поддерживает управление внешними хранилищами NFS v3 и v4.1. Это позволяет использовать их совместно с другими возможностями, такими как службы iSCSI, шифрование, дедупликация и компрессия. Теперь через интерфейс vCenter можно управлять всем жизненным циклом хранилищ на базе разных технологий и превратить его в средство контроля над всей инфраструктурой хранения.

3. Развертывание приложений с использованием Enhanced Cloud Native Storage

Напомним, что функции Cloud Native Storage появились еще VMware vSAN 6.7 Update 3. Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

Теперь эти функции получили еще большее развитие. Тома persistent volumes могут поддерживать шифрование и снапшоты. Также полностью поддерживается vSphere Add-on for Kubernetes (он же Project Pacific), который позволяет контейнеризованным приложениям быть развернутыми в кластерах хранилищ vSAN.

4. Прочие улучшения

Тут появилось довольно много нового:

• Integrated DRS awareness of Stretched Cluster configurations. Теперь DRS отслеживает, что виртуальная машина находится на одном сайте во время процесса полной синхронизации между площадками. По окончании процесса DRS перемещает машину на нужный сайт в соответствии с правилами.
• Immediate repair operation after a vSAN Witness Host is replaced. Теперь процедура замены компонента Witness, обеспечивающего защиту от разделения распределенного кластера на уровне площадок, значительно упростилась. В интерфейсе vCenter есть кнопка "Replace Witness", с помощью которой можно запустить процедуру восстановления конфигурации и замены данного компонента.
• Stretched Cluster I/O redirect based on an imbalance of capacity across sites. В растянутых кластерах vSAN можно настраивать защиту от сбоев на уровне отдельных ВМ за счет выделения избыточной емкости в кластере. В результате на разных площадках могут оказаться разные настройки, и появится дисбаланс по доступной емкости и нагрузке по вводу-выводу. vSAN 7 позволяет перенаправить поток ввода-вывода на менее загруженную площадку прозрачно для виртуальных машин.
• Accurate VM level space reporting across vCenter UI for vSAN powered VMs. Теперь в vSAN 7 есть возможности точной отчетности о состоянии хранилищ для виртуальных машин, точно так же, как и для остальных хранилищ в представлениях Cluster View и Host View.
• Improved Memory reporting for ongoing optimization. Теперь в интерфейсе и через API доступна новая метрика потребления памяти во времени. Она позволяет понять, как меняется потребление памяти при изменениях в кластере (добавление и удаление хостов, изменение конфигурации).
• Visibility of vSphere Replication objects in vSAN capacity views. vSAN 7 позволяет администраторам идентифицировать объекты vSphere Replication на уровне виртуальных машин и кластеров, что упрощает управление ресурсами для нужд репликации.
• Support for larger capacity devices. Теперь vSAN 7 поддерживает новые устройства хранения большой емкости и плотности носителей.
• Native support for planned and unplanned maintenance with NVMe hotplug. Для устройств NVMe теперь доступна функция горячего добавления и удаления, что позволяет сократить время и упростить процедуру обслуживания.
• Removal of Eager Zero Thick (EZT) requirement for shared disk in vSAN. Теперь общие диски в vSAN не требуется создавать в формате EZT, что ускоряет развертывание в кластере vSAN нагрузок, таких как, например, Oracle RAC.

Больше информации о новых возможностях можно почитать в даташите о vSAN 7. Ну а технические документы будут постепенно появляться на StorageHub. Как и VMware vSphere 7, планируется, что решение vSAN 7 выйдет в апреле этого года.

У VMware обнаружилась полезная интерактивная инфографика, которая наглядно показывает, что происходит с дисковыми объектами виртуальных машин хоста кластера хранилищ VMware vSAN, когда его переводят в режим обслуживания (Maintenance Mode). Напомним, что о том, как это работает, мы подробно писали вот тут.

Чтобы посмотреть различные сценарии работы данного режима, нужно открыть страничку по этой ссылке и нажать на кнопку Explore maintenance mode:

Далее можно будет выбрать основные параметры перевода в этот режим.

Сначала указываем способ миграции данных:

• Full data migration - данные копируются на другие хосты таким образом, чтобы обеспечить исполнения политики FTT/RAID на оставшемся наборе хостов ESXi при введении в режим обслуживания одного или двух хостов.
• Ensure Accessibility – это миграция только тех компонентов, которые есть в кластере в единственном экземпляре. При этом, для некоторых объектов на период обслуживания не будет соблюдена политика Failures to tolerate (FTT).
• No Data Migration – в этом случае никакие компоненты не будут перемещены с хоста, поэтому некоторые ВМ могут оказаться недоступными (если на этом хосте их дисковые компоненты находятся в единственном экземпляре, а уровень RAID недостаточен для предоставления доступа к объекту).

Потом надо задать значение политики FTT и тип организации избыточности RAID0 для FTT=0, RAID1 или RAID5 для FTT=1, RAID6 для FTT=2. А далее нужно указать, один или два хоста мы переводим в режим обслуживания.

Например, если мы укажем, что нам нужен тип миграции Full data migration, при этом надо соблюсти политику FTT=2/RAID-6, то система попросит добавить еще один хост ESXi в кластер, так как оставшихся 5 хостов в этом случае будет не хватать, чтобы обеспечить требуемые политики.

Ну а при выборе выполнимого сценария будет показана анимация происходящего при переводе одного или двух хостов в режим обслуживания процесса, который вовлекает перемещение дисковых объектов виртуальных машин на другие хосты.

Надо сказать, что не рекомендуется переводить сразу 2 хоста в режим обслуживания, так как это может привести к тому, что невозможно будет обеспечить требуемые политики FTT/RAID в имеющейся аппаратной конфигурации (хотя перевод двух хостов в maintenance mode вполне поддерживается со стороны vSAN).

В общем, интересная штука - попробуйте посмотреть, как визуализируются различные сценарии.

Сегодня мы расскажем об отличиях коммерческой и бесплатной версий одного из лучших решений для создания отказоустойчивых программных хранилищ под виртуальные машины StarWind Virtual SAN. Последний раз мы писали о сравнении возможностей платной и бесплатной версий в далеком 2017 году, и с тех пор, конечно же, много что изменилось.

Под конец года компания VMware выпустила очередной полезный администраторам VMware vSphere постер - VMware PowerCLI 11 Storage Module Reference Poster for vSAN. В постере приведено несколько полезных командлетов для последней версии PowerCLI, которые позволяют управлять хранилищами VMware vSAN с помощью модуля Storage.

С левой стороны перечислены все командлеты данного модуля, разбитые по группам, а справа приведены примеры использования различных команд и простых сценариев для выполнения типовых задач. Например, показано как узнать емкость датастора vSAN, установить VIB-пакет на хост vSAN или включить функцию vSAN Encryption в кластере.

Скачать постер VMware PowerCLI 11 Storage Module Reference Poster for vSAN можно по этой ссылке.

Многие администраторы виртуальных инфраструктур в курсе про технологию NVMe (интерфейс Non-volatile Memory дисков SSD), которая была разработана для получения низких задержек и эффективного использования высокого параллелизма твердотельных накопителей. Такие устройства хоть и стоят дороже, но уже показывают свою эффективность за счет использования десятков тысяч очередей команд, что дает очень низкие задержки, требующиеся в таких сферах, как системы аналитики реального времени, онлайн-трейдинг и т.п.

К сожалению, протокол iSCSI (да и Fibre Channel тоже) разрабатывался тогда, когда инженеры еще не думали об архитектуре NVMe и высоком параллелизме, что привело к тому, что если использовать iSCSI для NVMe, использование таких хранилищ происходит неэффективно.

Главная причина - это одна очередь команд на одно устройство NVMe, которую может обслуживать iSCSI-протокол, весь смысл параллелизма теряется:

Вторая проблема - это то, что iSCSI использует процессор для диспетчеризации операций ввода-вывода, создавая дополнительную нагрузку на серверы, а также имеет некоторые сложности по перенаправлению потоков операций для нескольких контроллеров NVMe и устройств хранения на них.

Для этого и был придуман протокол NVMe over Fabrics (NVMe-oF), который не имеет таких ограничений, как iSCSI. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP.

Компания StarWind сделала свою реализацию данного протокола для продукта StarWind Virtual SAN, чтобы организовать максимально эффективное использование пространства хранения, организованного с помощью технологии NVMe. Об этом было объявлено еще осенью прошлого года. Он поддерживает 64 тысячи очередей, в каждой из которых, в свою очередь, может быть до 64 тысяч команд (в реальной жизни в одной очереди встречается до 512 команд).

Важный момент в реализации NVMe-oF - это применение технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы.

Также RDMA позволяет маппить несколько регионов памяти на одном NVMe-контроллере одновременно и организовать прямое общение типа точка-точка между инициаторами разных хостов (несколько Name Space IDs для одного региона) и этими регионами без нагрузки на CPU.

Такой подход, реализованный в продуктах StarWind, дает потрясающие результаты в плане производительности, о которых мы писали вот в этой статье. К этой статье можно еще добавить то, что реализация инициатора NVMe-oF на базе Windows-систем и таргета на базе Linux (который можно использовать в программно-аппаратных комплексах StarWind Hyperconverged Appliances, HCA) дала накладные издержки на реализацию всего 10 микросекунд по сравнению с цифрами, заявленными в даташитах производителя NVMe-устройств. Знающие люди поймут, насколько это мало.

Еще надо отметить, что бесплатный продукт StarWind NVMe-oF initiator - это единственная программная реализация инициатора NVMe-oF на сегодняшний день. В качестве таргета можно использовать решения Intel SPDK NVMe-oF Target и Linux NVMe-oF Target, что позволяет не зависеть жестко от решений StarWind.

Подробнее о StarWind NVMe-oF initiator можно узнать вот в этой статье. А загрузить его можно по этой ссылке.

На сайте проекта VMware Labs очередное обновление: вышло интересное средство для мониторинга кластеров VMware vSAN - мобильная утилита vSAN Live. С помощью данного приложения для iOS (9.0+) или Android (4.1+) можно организовать мониторинг инфраструктуры отказоустойчивых хранилищ vSAN, находясь за пределами инфраструктуры компании (например, в отпуске или командировке).

Полный список возможностей утилиты vSAN Live:

• Дэшборд с обзором всех кластеров vSAN.
• Полный набор выполняемых для vSAN хэлс чеков.
• Просмотр структуры кластера, включая Fault domain и статусы хостов.
• Простое переключение между серверами vCenter.
• Просмотр конфигурации кластера, включая настройки vSAN и статус сервиса.
• Полнофункциональный мониторинг производительности для виртуальных машин и кластера в целом, а также мониторинг емкости хранилищ кластера.

Самое полезное - это возможность выполнять health checks, что даст возможность понять, что и где сломалось в кластере vSAN:

Скачать приложение vSAN Live можно по этим ссылкам:

Для начала работы с приложением нужно скачать сертификат, расположенный на сервере vCenter по адресу:

https://<VC_FQDN>/afd/vecs/ca

Для установки сертификата на iOS:

• Идем в Settings -> General -> Profiles -> CA -> Install
• Далее: Settings -> About -> Certificate Trust Settings -> CA (enable)
  

Для установки сертификата на Android:

• Открываем сертификат -> Даем ему имя -> Ставим "Credential Use: VPN and apps" -> жмем OK

Пока это всего лишь первая версия утилиты, в дальнейшем, будем надеяться, там появится еще больше интересных функций.

В рамках прошедшей конференции VMworld Europe 2019 было сделано не так много анонсов, как на главной конференции года VMworld 2019. Между тем, кое-что новое там все-таки было анонсировано. Например, было объявлено о выходе новой версии продукта vRealize Log Insight Content Pack for vSAN 2.2. Напомним, что о версии данного контент-пака 2.1 мы писали в январе этого года вот тут.

Напомним, что продукт позволяет получить следующие возможности в рамках функционала Log Insight:

• Быстрая идентификация проблем за счет специализированных дэшбордов, отображающих состояние кластеров vSAN.
• Возможность использования различных комплексных фильтров для поиска нужной информации в логах vSAN.
• Визуализация необходимых параметров и запросов, что позволяет определить аномалии в различных аспектах инфраструктуры.
• Мощный движок алертинга, который позволяет мониторить логи vSAN на предмет возможных проблем и оповещать администраторов.
• Помощь администраторам - каждый виджет включает информацию о его назначении со ссылками на документацию и базу знаний VMware, что позволяет понять характер и назначение отображаемых данных.

Давайте посмотрим, что нового появилось в версии Log Insight Content Pack for vSAN 2.2:

1. Новый дэшборд vSAN Overview.

Он отображает основные активности и события, происходящие как на пользовательском уровне, так и на уровне ядра. События разделяются на общую информацию, предупреждения и ошибки.

Это позволяет быстрее обнаруживать аномалии в поведении кластера VMware vSAN.

2. Новый раздел Storage Policy Events.

Он включает в себя мониторинг следующих активностей:

• Создание и удаление новых политик хранилищ.
• Изменение политики для ВМ или назначение ей новой политики.
• Изменение свойств самой политики.
• Изменение политик на уровне объектов.

Механизм обновления контент-пака

Для Log Insight механизм обновления контент-паков всегда был весьма простым:

После обновления контент-пака у вас появятся новые дэшборды, описанные выше, но чтобы появились виджеты политик хранилищ, нужно установить Log Insight Agent на vCenter Server. Для этого нужно загрузить пакет Linux RPM (32-bit/64-bit) через Log Insight Administration UI:

После этого нужно скопировать RPM во временную папку на vCenter Server с помощью WinSCP или Veeam FastSCP. Далее на vCSA нужно запустить следующую команду:

rpm -i VMware-Log-Insight-Agent-<version-and-build-number>.rpm

После установки пакета нужно убедиться, что соответствующий статус отображается в интерфейсе:

Далее настройте и включите vCenter (Linux) SPBM agent group на сервере vCenter как показано ниже (это позволит Log Insight собирать события SPBM с сервера vCenter):

После того, как вы нажмете кнопку Copy Template, вам покажут настройки активного агента. Убедитесь, что все параметры указаны корректно и нажмите Save Agent Group:

Новые возможности по трекингу активностей SPBM позволят вам выполнять следующие задачи:

• Отслеживать резкие изменения в используемой емкости кластера.
• Идентифицировать причины неожиданных изменений в производительности ВМ.
• Идентифицировать причины инициирования трафика ресинхронизации.
• Отслеживать соблюдение политик хранилищ за пределами уровня кластера.
• Использовать Webhooks для оповещения других приложений, которым может быть полезна информация от Log Insight.

Скачать VMware vRealize Log Insight Content Pack for vSAN 2.2 можно по этой ссылке.

На днях, еще до начала конференции VMworld Europe 2019, компания VMware рассказала об интересном сервисе - Skyline Health for vSAN. Как вы помните, сервис VMware Skyline - это проактивная технология VMware для предоставления расширенной технической поддержки некоторым клиентам для продуктов vSphere и NSX.

С помощью технологии VMware Skyline пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут просматривать некоторые заключения о работе виртуальной инфраструктуры и основные рекомендации по ее улучшению, которые содержатся в специальном отчете Skyline Operational Summary Report (OSR).

Также инженеры техподдержки VMware в рамках решения проблем заказчиков могут видеть весь их Inventory, а также все их обращения в техническую поддержку (Support Requests, SRs). Все это позволяет службам Global Support Services (GSS) быстро и эффективно решать проблемы заказчиков, а что более важно - предотвращать их.

Новое решение от VMware объединяет 2 продукта - vSAN Health и сервис Skyline. Skyline Health for vSAN предоставляет пользователям инструменты для самостоятельного обследования процессов конфигурации, патчинга, апгрейда и безопасности решений vSAN 6.7. Самое приятное - это то, что все пользователи с активной поддержкой получают Skyline Health for vSAN бесплатно.

Решение Skyline Health использует данные о тысячах инсталляций VMware vSAN для проактивного обнаружения проблем в вашей инфраструктуре, при этом само оно не отправяляет наружу никаких чувствительных данных. Сервис Skyline интегрирован с базой знаний VMware KB, а также содержит в себе список лучших практик для устранения наиболее частно встречающихся проблем.

Для работы Skyline вам потребуется, чтобы vCenter имел доступ в интернет и был участником Customer Experience Improvement Program (CEIP). В плане интерфейса vSphere Client раздел "Skyline Health" заменит собой "Health" и будет содержать как рекомендации Skyline, так и суммарную информацию vSAN Health. Сервис Skyline Health будет доступен для vSphere 6.7P01 (или vSAN 6.7 U3a), а также более поздних версий платформы.

Кроме того, сам проект Skyline претерпел несколько изменений. Теперь появилось решение Skyline Advisor, которое предназначено для пользователей с уровнем поддержки Production / Premier. Это решение включает в себя поддержку таких продуктов, как vSphere, vSAN, NSX, vROps, Horizon. Помимо этого туда включается инфраструктура VMware Cloud Foundation и Dell EMC VxRail.

Также поддержка распространяется на такие компоненты, как решения VMware Cloud Foundation и Dell EMC VxRail, а также гиперконвергентные системы, созданные в кооперации с другими вендорами.

Решение Skyline Advisor расширяет поддержку продуктов VMware и для старых версий (например, vSphere 5.5). Также пользователи вместе с продуктом получают и решение LogAssist, которое автоматизирует сбор и загрузку логов (это может оказаться очень полезным при обращении в саппорт).

Пользователи поддержки уровня Premier получают еще несколько дополнительных функций, таких как расширенные рекомендации и отчеты, а также план по решению проблем и восстановлению правильной конфигурации инфраструктуры.

Решение VMware Skyline Health for vSAN будет доступно для пользователей в ближайшие месяцы.

В последних числах августа компания StarWind Software, выпускающая продукты для организации хранилищ под виртуализацию, выпустила обновленную версию решения для создания iSCSI-хранилищ на платформах vSphere и Hyper-V - StarWind Virtual SAN V8 build 13182. Давайте посмотрим, что нового появилось в этом продукте...

На сайте проекта VMware Labs за последние дни появилась пара интересных обновлений полезных утилит. Первое - это апдейт средства vSAN Performance Monitor 1.2, предназначенного для мониторинга и визуализации (в Grafana) метрик в среде отказоустойчивых кластеров VMware vSAN.

С помощью этих данных администраторы смогут диагностировать проблемы, а также распознавать текущие и намечающиеся узкие места в инфраструктуре, которые могут оказаться причиной низкой производительности.

В версии vSAN Performance Monitor 1.2 появились следующие улучшения:

• Исправлена проблема с настройкой CA-сертификатов
• Некоторые доработки агента, собирающиего данные
• Убран анонимный сбор статистики от influxdb

Скачать vSAN Performance Monitor 1.2 можно по этой ссылке.

Второе существенное обновление в Labs - это апдейт утилиты vRealize Operations REST Notifications Helper 1.3. О прошлой версии 1.2 этого средства мы писали вот тут. Напомним, что эта штука позволяет администратору vROPs изменять свойства алерта перед его отправкой на сторону.

В данном обновлении появились следующие новые функции:

• Добавлена конфигурация предпочитаемого HTTP-запроса
• Добавлена конфигурация маппинга критичности алерта
• Добавлены черные списки с полем resourceName
• Добавлена настройка структуры конечного устройства (endpoint) для обработки разного поведения на базе состояний сработавшего/несработавшего триггера
• Добавлено описание симптомов в одну строку как и для рекомендаций.
• Различные исправления ошибок

Обновленный vRealize Operations REST Notifications Helper 1.3 можно скачать по этой ссылке.

Некоторое время назад мы писали о новых возможностях решения для создания отказоустойчивых хранилищ на базе хост-серверов VMware vSAN 6.7 Update 3. Среди прочего там появилось пара расширенных настроек, на которые обратил внимание Cormac Hogan. Давайте посмотрим, чем управляют эти Advanced Options в кластере.

Чтобы увидеть новые опции, надо в vSphere Client пойти в Cluster > Configure > vSAN > Services > Advanced Options, где можно увидеть параметры Large Cluster Support и Automatic Rebalance:

Первая настройка, как понятно из названия, регулирует возможность создания кластеров, которые имеют более 32 узлов. Ранее, чтобы расширить кластер, нужно было выставить параметр TcpipHeapMax на всех его хост-серверах ESXi. Теперь это удобно сделано в Advanced Options и применяется на уровне всего кластера.

Настройка Large Cluster Support требует перезагрузки каждого из хост-серверов:

Если вы не перезагрузите хосты, что в разделе статуса "vSAN extended configuration in sync" будут отображаться ошибки:

Вторая настройка, Automatic Rebalance, относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства. По умолчанию пороговое значение составляет 30%, что означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.

Также в разделе vSAN Disk Balance вы найдете информацию по использованию дисковой подсистемы кластера:

В случае, если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.

На блогах VMware появилась интересная статья о том, как работает связка кэширующего яруса (Cache tier) с ярусом хранения данных (Capacity tier) на хостах кластера VMware vSAN в контексте производительности. Многие пользователи задаются вопросом - а стоит ли ставить более быстрые устройства на хосты ESXi в Capacity tier и стоит ли увеличивать их объем? Насколько это важно для производительности?

Системы кэширования работают в датацентре на всех уровнях - это сетевые коммутаторы, процессоры серверов и видеокарт, контроллеры хранилищ и т.п. Основная цель кэширования - предоставить высокопроизводительный ярус для приема операций ввода-вывода с высокой интенсивностью и малым временем отклика (это обеспечивают дорогие устройства), после чего сбросить эти операции на постоянное устройство хранения или отправить в нужный канал (для этого используются уже более дешевые устройства).

В кластере vSAN это выглядит вот так:

Второе преимущество двухъярусной архитектуры заключается в возможности манипуляции данными не на лету (чтобы не затормаживать поток чтения-записи), а уже при их сбрасывании на Capacity tier. Например, так работают сервисы компрессии и дедупликации в VMware vSAN - эти процессы происходят уже на уровне яруса хранения, что позволяет виртуальной машине не испытывать просадок производительности на уровне яруса кэширования.

Общая производительность двухъярусной системы зависит как от производительности яруса хранения, так и параметров яруса кэширования (а именно скорость работы и его объем). Ярус кэширования позволяет в течение определенного времени принимать операции ввода-вывода с очень большой интенсивностью, превышающей возможности приема яруса хранения, но по прошествии этого времени буфер очищается, так как требуется время для сброса данных на уровень постоянного хранения.

С точки зрения производительности это можно представить так (слева система с ярусом кэширования и хранения, справа - только с ярусом хранения):

Оказывается, в реальном мире большинство профилей нагрузки выглядят именно как на картинке слева, то есть система принимает большую нагрузку пачками (burst), после чего наступает некоторый перерыв, который устройства кэширования кластера vSAN используют для сброса данных на постоянные диски (drain).

Если вы поставите более производительное устройство кэширования и большего объема, то оно сможет в течение большего времени и быстрее "впитывать" в себя пачки операций ввода-вывода, которые возникают в результате всплесков нагрузки:

Но более быстрое устройство при равном объеме будет "наполняться" быстрее при большом потоке ввода-вывода, что уменьшит время, в течение которого оно сможет обслуживать такие всплески на пиковой скорости (зато во время них не будет проблем производительности). Здесь нужно подбирать устройства кэширования именно под ваш профиль нагрузки.

С точки зрения устройств кэширования и хранения, кластер VMware vSAN представлен дисковыми группами, в каждой из которых есть как минимум одно устройство кэширования и несколько дисков хранения:

Для устройств кэширования на уровне одной дисковой группы установлен лимит в 600 ГБ. Однако это не значит, что нельзя использовать ярус большего объема. Мало того, некоторые пользователи vSAN как раз используют больший объем, так как в этом случае запись происходит во все доступные ячейки SSD (но суммарный объем буфера все равно не превышает лимит), что приводит к меньшему изнашиванию устройств в целом. Например, так происходит в кластере All-flash - там все доступная свободная емкость (но до 600 ГБ) резервируется для кэша.

Надо еще понимать, что если вы поставите очень быстрые устройства кэширования, но небольшого объема - они будут быстро заполняться на пиковой скорости, а потом брать "паузу" на сброс данных на ярус хранения. Таким образом, здесь нужен компромисс между объемом и производительностью кэша.

На базе сказанного выше можно дать следующие рекомендации по оптимизации производительности двухъярусной системы хранения в кластерах VMware vSAN:

• Старайтесь использовать устройства кэширования большего объема, чтобы они могли впитывать большой поток ввода-вывода в течение большего времени. Производительность устройств уже рассматривайте во вторую очередь, только если у вас уж очень большой поток во время всплесков, который нужно обслуживать очень быстро.
• Добавляйте больше дисковых групп, каждую из которых может обслуживать свое устройство кэширования. На уровне дисковой группы установлен лимит в 600 ГБ, но всего на хосте может быть до 3 ТБ буфера, поделенного на 5 дисковых групп.
• Используйте более производительные устройства в ярусе хранения - так сброс данных буфера (destage rate) на них будет происходить быстрее, что приведет к более быстрой готовности оного обслуживать пиковую нагрузку.
• Увеличивайте число устройств хранения в дисковой группе - это увеличит скорость дестейджинга данных на них в параллельном режиме.
• Отслеживайте производительность кластера с помощью vSAN Performance Service, чтобы увидеть моменты, когда ярус кэширования захлебывается по производительности. Это позволит соотнести поведение буфера и профиля нагрузки и принять решения по сайзингу яруса кэширования и яруса хранения.
• Используйте самые последнии версии VMware vSAN. Например, в vSAN 6.7 Update 3 было сделано множество программных оптимизаций производительности, особенно в плане компрессии и дедупликации данных. Всегда имеет смысл быть в курсе, что нового появилось в апдейте и накатывать его своевременно.

Перед самой конференцией VMworld 2019, которая прошла на прошлой неделе в Сан-Франциско, компания VMware анонсировала полезный сервис ports.vmware.com, где любой желающий может вывести порты и соединения по различным протоколам для следующих продуктов серверной линейки:

• vSphere
• vSAN
• NSX for vSphere
• vRealize Network Insight
• vRealize Operations Manager
• vRealize Automation

Выглядит это вот таким образом (кликабельно):

Как мы видим, в левой части можно выбрать один или несколько продуктов, для которых будут выведены все соединения с указанием портов и характера взаимодействий. Это позволит правильно настроить сетевые экраны, через которые происходит коммуникация между компонентами виртуальной инфраструктуры.

Результаты можно вывести в отдельный красивый PDF-документ, либо распечатать. Что удобно, в колонке version указана версия продукта, для которой эта информация актуальна.

Если раньше всю эту информацию приходилось вылавливать из статей базы знаний VMware, а также подглядывать в различные постеры, то теперь все очень удобно организовано на одном экране (и что важно с возможностью поиска по результатам). Также есть удобная функция - сортировка по колонкам, например, по номеру порта - когда хочется найти конкретный порт или диапазон.

В общем, пользуемся - ports.vmware.com.

На прошедшей конференции VMworld 2019 было сделано немало интересных анонсов (о самых интересных из них мы рассказываем тут), один из них - это определенно технологическое превью Project Magna (год назад мы рассказывали о начале разработки этого продукта). Это облачное решение VMware, которое предназначено для постоянной непрерывной оптимизации инфраструктуры отказоустойчивых хранилищ VMware vSAN.

Magna представляет собой движок, который позволяет проводить самооптимизацию решения vSAN и его тюнинг, то есть автоматически тонко настраивать параметры кластеров хранилищ, наблюдая за их работой и постоянно анализируя метрики. Работать это будет как SaaS-продукт, который из облака будет осуществлять контроль над инфраструктурой vSAN:

Суть движка заключается в постоянной работе AI/ML-алгоритмов, которые непрерывно собирают и анализируют конфигурации и метрики хранилищ, после чего вносят корректировки, имея в виду главную цель - не ухудшить производительность. Как только алгоритм понимает, что в результате изменения настроек стало хуже, он откатывает действие назад, запоминает и анализирует эту ситуацию, дополняя свои внутренние алгоритмы оптимизаций.

В качестве ML-алгоритма используется так называемый Reinforcement Learning, который анализирует заданные вами KPI по производительности и сравнивает их с аналогичными конфигурациями для похожих нагрузок. Этот алгоритм постоянно проверяет тысячи различных сценариев конфигурации, чтобы найти оптимальный именно для вашей инфраструктуры. Само испытание производится методом проб и ошибок:

Также продукт vRealize Operations можно будет интегрировать с Project Magna таким образом, чтобы первый мог получить от последнего нужные конфигурации, а пользователь может поставить настройку селф-тюнинга, которая будет следовать заданной вами цели.

Цели (KPI) могу быть заданы в виде следующих вариантов:

• Read Performance - все настраивается для наименьших задержек на чтение (latency), увеличения пропускной способности (максимум для этого будет использоваться до 10% памяти хоста).
• Write Performance - конфигурация стремится уменьшить задержки и увеличить производительность на запись (пренебрегая скоростью чтения).
• Balanced - оптимизация сбалансированного режима чтения-записи, в зависимости от требований рабочей нагрузки.

Также полученные целевые KPI можно будет сравнить со средними по отрасли (эти данные будут агрегироваться от клиентов VMware). Для глубокого понимания происходящего в консоли Magna будет доступен график производительности, который в ключевых точках будет показывать, какие изменения были сделаны:

Например, на этом скриншоте мы видим, что Magna увеличила размер кэша на чтение до 50 ГБ 23 июля - и это благотворно повлияло на performance index.

Больше о решении Project Magna можно узнать из следующих сессий VMworld 2019:

• HCI1620BU – Artificial Intelligence and Machine Learning for Hyperconverged Infrastructure
• MLA2021BU – Realize your Self-Aware Hybrid Cloud with Machine Learning
• HCI1650BU – Optimize vSAN performance using vRealize Operations and Reinforcement Learning

Доступность Project Magna ожидается в следующем году.

На сайте проекта VMware Labs появилась очередная интересная утилита - виртуальный модуль vSAN Performance Monitor, предназначенный для мониторинга метрик в среде отказоустойчивых кластеров VMware vSAN и их визуализации.

С помощью vSAN Performance Monitor администратор может на регулярной основе собирать метрики производительности в кластерах vSAN, которые потом визуализуются на уже преднастроенных дэшбордах, встроенных в продукт.

С помощью этих данных администраторы смогут диагностировать проблемы, а также распознавать текущие и намечающиеся узкие места в инфраструктуре, которые могут оказаться причиной низкой производительности.

Напомним, что 5 лет назад была выпущена похожая утилита - vSAN Observer, ну а создатели vSAN Performance Monitor открыто пишут, что при разработке вдохновлялись именно ей.

Само средство поставляется в виде виртуального модуля (Virtual Appliance), который реализует 3 основных компонента:

• Коллектор Telegraf - это агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
• InfluxDB - собственно, сама база данных, хранящая метрики.
• Grafana - это фреймворк, который используется для визуализации метрик из базы.

После развертывания администратору лишь нужно указать простые настройки и подключить коллектор к одному или нескольким целевым кластерам и стартовать сервис. После этого данные будут собираться на периодической основе и могут быть визуализованы в любой момент.

В качестве платформы и целевой машины для vSAN Performance Monitor поддерживаются vSphere 6.0 и VM hardware 11  (или более поздние). Для работы утилиты вам потребуется включить службу Virtual SAN Performance Service (о том, как это сделать, написано вот тут).

Скачать vSAN Performance Monitor можно по этой ссылке.